NOM¶

mlock, munlock, mlockall, munlockall - Verrouiller et déverrouiller la mémoire

SYNOPSIS¶

#include <sys/mman.h>

int mlock(const void *addr, size_t len);
int munlock(const void *addr, size_t len);

int mlockall(int flags);
int munlockall(void);

DESCRIPTION¶

mlock() et mlockall() verrouillent respectivement une partie et l'ensemble de l'espace d'adressage du processus appelant dans la mémoire physique, pour empêcher cette mémoire d'être évincée dans l'espace d'échange (swap). munlock() et munlockall() ont l'effet inverse, respectivement déverrouillant une partie ou l'ensemble de l'espace d'adressage du processus appelant, afin que les pages dans la zone indiquée puissent à nouveau être évincées dans le swap si le gestionnaire de mémoire du noyau l'exige. Le verrouillage et le déverrouillage de mémoire se font par multiples d'une page.

VALEUR RENVOYÉE¶

S'ils réussissent, ces appels système renvoient 0. En cas d'erreur, ils renvoient -1, errno contient le code d'erreur, et les verrouillages de mémoire du processus ne sont pas modifiés.

ERREURS¶

ENOMEM

(Linux 2.6.9 et plus récents) L'appelant avait une limite souple RLIMIT_MEMLOCK non nulle, mais a tenté de verrouiller plus de mémoire que la quantité autorisée. Cette limite n'est pas imposée si le processus est privilégié (CAP_IPC_LOCK).

ENOMEM

(Linux 2.4 et précédents) Le processus appelant a essayé de verrouiller plus de la moitié de la mémoire vive.

EPERM

(Linux 2.6.9 et plus récents) L'appelant n'était pas privilégié (CAP_IPC_LOCK) et sa limite souple RLIMIT_MEMLOCK était à 0.

EPERM

(Linux 2.6.8 et précédents) L'appelant n'a pas les privilèges appropriés pour appeler munlockall(). Sous Linux, la capacité CAP_IPC_LOCK est nécessaire.

Pour mlock() et munlock() :

EAGAIN

Une partie (ou l'ensemble) de l'espace d'adressage indiqué n'a pas pu être verrouillée.

EINVAL

len est négatif.

EINVAL

(Pas sous Linux) addr n'est pas un multiple de la taille de page.

ENOMEM

Une partie de la zone indiquée ne correspond pas à des pages projetées dans l'espace d'adressage du processus.

Pour mlockall() :

EINVAL

Des flags inconnus étaient demandés.

Pour munlockall() :

EPERM

(Linux 2.6.8 et précédents) L'appelant n'est pas privilégié (CAP_IPC_LOCK).

CONFORMITɶ

POSIX.1-2001, SVr4.

DISPONIBILITɶ

Sur les systèmes POSIX où mlock() et munlock() sont disponibles, la constante symbolique _POSIX_MEMLOCK_RANGE est définie dans <unistd.h> et le nombre d'octets par page peut être déterminé grâce à la constante PAGESIZE si définie dans <limits.h> ou en appelant sysconf(_SC_PAGESIZE).

Sur les systèmes POSIX sur lesquels mlockall() et munlockall() sont disponibles, la constante symbolique _POSIX_MEMLOCK est définie dans <unistd.h> comme étant une valeur supérieure à 0. (Voir aussi sysconf(3).)

NOTES¶

Il y a deux domaines principaux d'applications au verrouillage de pages : les algorithmes en temps réel, et le traitement de données confidentielles. Les applications temps réel réclament un comportement temporel déterministe, et la pagination est, avec l'ordonnancement, une cause majeure de délais imprévus. Ces algorithmes basculent habituellement sur un ordonnancement temps‐réel avec sched_setscheduler(2). Les logiciels de cryptographie manipulent souvent quelques octets hautement confidentiels, comme des mots de passe ou des clés privées. À cause de la pagination, ces données secrètes risquent d'être transférées sur un support physique où elles pourraient être lues par un ennemi longtemps après que le logiciel se soit terminé. (Soyez toutefois conscient que le mode suspendu sur les portables et certains ordinateurs de bureau sauvegarde une copie de la mémoire sur le disque, quels que soient les verrouillages.)

Les processus temps‐réel utilisant mlockall() pour éviter les délais dus à la pagination doivent réserver assez de pages verrouillées pour la pile avant d'entrer dans la section temporellement critique, afin qu'aucun défaut de page ne survienne lors d'un appel de fonction. Cela peut être obtenu en appelant une fonction qui alloue une variable automatique suffisamment grande (comme un tableau) et écrit dans la mémoire occupée par ce tableau afin de modifier ces pages de pile. Ainsi, suffisamment de pages seront projetées pour la pile et pourront être verrouillées. Les écritures bidon permettent de s'assurer que même les pages copiées à l'écriture ne causeront pas de défaut de page dans la section critique.

Les verrouillages de mémoire ne sont pas hérités par le fils lors d'un fork(2), et sont automatiquement supprimés (déverrouillés) au cours d'un execve(2) ou lorsque le processus termine.

Le verrouillage de mémoire sur une zone est automatiquement enlevé si la zone est invalidée par munmap(2).

Il n'y a pas d'empilement des verrouillages mémoire, ce qui signifie qu'une page verrouillée plusieurs fois par mlock() ou mlockall() sera libérée en un seul appel à munlock() pour la zone mémoire correspondante ou par un appel à munlockall(). Les pages qui sont verrouillées par plusieurs zones, ou par plusieurs processus restent verrouillées en mémoire vive tant qu'il y a au moins un processus ou une zone qui les verrouille.

BOGUES¶

Dans les noyaux Linux de la branche 2.4 jusqu'à 2.4.17 inclus, le paramètre MCL_FUTURE de mlockall() était hérité par le fils après un fork(2) en raison d'un bogue. Cela a été corrigé dans le noyau 2.4.18.

Depuis le noyau 2.6.9, si un processus privilégié appelle mlockall(MCL_FUTURE) et réduit ses privilèges plus tard (perd la capacité CAP_IPC_LOCK, par exemple en prenant un UID effectif non nul), les allocations de mémoires suivantes (p.ex. mmap(2), brk(2)) échoueront si la limite RLIMIT_MEMLOCK est dépassée.

VOIR AUSSI¶

mmap(2), setrlimit(2), shmctl(2), sysconf(3), capabilities(7)

COLOPHON¶

Cette page fait partie de la publication 3.23 du projet man-pages Linux. Une description du projet et des instructions pour signaler des anomalies peuvent être trouvées à l'adresse <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION¶

Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <URL:http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet perkamon <URL:http://alioth.debian.org/projects/perkamon/>.

Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003), Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et l'équipe francophone de traduction de Debian (2006-2009).

Veuillez signaler toute erreur de traduction en écrivant à <perkamon-l10n-fr@lists.alioth.debian.org>.

Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « LC_ALL=C man <section> <page_de_man> ».